All in all we are pleased with the result. We feel that we have created a
functional prototype of the system we intended in a relatively short amount
of time. As with all software projects though, there are things that could
be improved. In this section we perform a fair introspection of the pr3Da
system and identify the things that went right as well as what needs improvement.

\subsection{The Good}
We believe that the general system design is clean and simple and should be
easy to use for any capable developer wishing to display photo collections
in a three dimensional space. The system provides a visually pleasing
environment to browse through pictures. Being able to extend the layout and 
transition elements of the system is of great value too. Extending the layout 
mechanism enables external applications to use the three dimensionality to 
visually present valuable information while extending the transition system 
primarily augments the aesthetics of the application (although transitions 
could very well also be used for informational benefit). The lazy loading image 
plugin mechanism is also something that we are proud of, making it easy to load 
pictures from every conceivable data source.

Perhaps most important though, is the fact that we enjoy the visual aspect of 
viewing photos in this 3D environment. We are confident that if combined with
a powerful tool such as Prada it should be easy to create the ultimate 
application for photo browsing!

\subsection{The Bad}
Our biggest annoyances with the pr3Da system today mostly relate to 
technical aspects of the Panda3D platform upon which pr3Da is built. The
biggest nuance is probably the fact that Panda3D uses an internal image 
representation class called PNMImage. This class is very limited in
functionality and also has some performance issues. A specific problem
we had was to load an alpha channel from a separate image and combine it
into an already loaded PNMImage instance. This turned out to be impossible,
forcing us to programmatically construct the alpha channel for the reflection
effect. What we would have liked to see is Panda3D using the PIL (Python 
Imaging Library) data structures for their image representation. This would 
enable a range of powerful image manipulation tools that would have been of 
great use to us.

A limitation of the pr3Da system design is the inability to dynamically add visual 
effects to a specific image. This would enable external applications to provide their
own effects similar to what is possible with the transition and layout mechanisms.
This is not difficult to implement but got left out due to time constraints.

The reflection effect was a source of joy and tears. We were very happy with how
visually pleasing the effect turned out to be but at the same time, the aforementioned
limitation of PNMImage resulted in very poor performance. Another problem with the
reflection effect is our implementation of it. Currently you can choose to turn it on
and off for each image. This always displays the reflection at the same position 
relative to the image, regardless of the location of the image in the virtual world.
This is another thing that could be fixed but we didn't get around to it in time.

\subsection{What Got Left Out}
Although we managed to implement most of what we set out to do, there were a few things
that got left out.

In our project proposal, we mentioned the ability to zoom into and stretch image sets.
As such, this functionality is inherent in Panda3D since zooming is really just moving 
the camera closer and stretching can be achieved by changing the shape of a set. We
decided not to spend time on implementing a user interface for doing that. That would have 
required a decent amount of groundwork which wasn't the focus of this project in our oppinion.

Having different axes types is another thing that we didn't implement per se. Again, one
could argue that the functionality is there as it is the job of a layout implementation to
decide how to use the three axes. For instance, we implemented a GridLayout which essentially 
regards all axes as categorical (discrete) while our RandomLayout implementation regards them
as linear.

As discussed in previous sections, lazy loading mipmapping and flocking transitions were not 
implemented.

We would have liked to implement more image loading plugins to retrieve images from other
sources such as Flickr. This was yet another thing that we didn't have time to add.